NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/misc-part1/3640

Internet Message Format | 1996-08-05 | 5.2 KB

Path: felix.teclink.net!usenet
From: [e-mail] (rad)
Newsgroups: comp.sys.amiga.misc
Subject: Re: OS features
Date: 31 Jan 1996 02:14:30 GMT
Organization: TECLink Internet Services: [e-mail]
Message-ID: <[e-mail]>
References: <4e657d$[e-mail]>
NNTP-Posting-Host: tc1_1.teclink.net
X-Newsreader: THOR 2.22 (Amiga;TCP/IP) *UNREGISTERED*


>Michael van Elst ([e-mail]) wrote:
>: [e-mail] (Wayne Fisher) writes:

><...>
>: >    - new programs' code and data would be protected from access by
>: >    another
>: >      process unless explicitly allowed by the program.

>: Kills close to all system functions. You had to write a completely new
>: AmigaOS.

>Maybe not. Let's say (as you suggested earlier) that some subsystems
>(e.g. Intuition) have the permission to read and write any memory region.
>Intuition functions would have to check if the pointers received from
>process A point into A's memory and, of course, if they are consistent
>and don't corrupt Intuition's internal data when used (That's a good piece
>of work for the programmers and for Intuition at runtime but I guess it's
>possible).
>Programs which want to browse internal data structures of Intuition are
>either given permission or fail.

First intuition is currently called within all the tasks which open it.  In
order to allow intuition to access any memory region all processes with
intuition open (practically all processes) must be able to access any memory
region, or intuition must be changed drastically to run out of a separate
process(es) in which case you add the large overhead of a context switch
for each intuition function call.  The same goes for many other libraries too.

><...>
>: >"much more"? I don't think a few percentages is "much more".

>: You forget that memory protection is nothing if you cannot protect
>: the system from invalid parameters to system functions. Most system
>: functions however use shared data structures.

>How about this: Write access to a data structure shared between a process
>and Intutition marks the data structure as dirty and Intuition has to
>perform consistency checks again before using it.

Are you willing to sacrifice the speed to do these checks on almost every
intiution function call?

>: The whole concept of device drivers had to be changed.
>: BOOPSI is dead.
>: System hooks are dead.

>Device drivers would have to be a subsystem with the license to kill
>(read/write everything). System hooks would be restricted to programs
>which were given special permission.

The problems here are that you are punching wholes in your memory protection
for almost all software out there, and requiring major OS changes... This is
what people have been trying to point out for years.

>: >It
>: >just means that you can't pass pointers between processes and the
>: >machine becomes more stable.

>: Unfortunately most parameters are passed by pointers. You do have
>: to change everything.

>Old programs could use one address space and pass pointers as much as
>they want to. Maybe if A calls PutMsg() it gives the receiving process B
>the permission to read/write its memory. New programs could
>also use PutMsg() but they'd allocate the message from a special pool
>and the other task receives only read/write permission for this pool.
>The private memory of new programs wouldn't have to be in the global
>address space.
>Another difference between old and new programs could be that the memory
>of old programs must not be swapped while new programs can decide for
>each of their pools if it has MEMF_SWAP set or not.

Part of the problems with this is current software usually does not allocate
memory for messages separately from everything else leaving the OS guessing at
the size of the messages.  Further messages usually contain pointers to other
blocks of memory outside of the message which may need to be both read and
written by the receiver.  Therefor to support current programs the sender's
entire memory space must be made available to the receiver and further must be
mapped into the exact same address space for the receiver as the sender.
Before you know it every process has access to almost every other processes
memory.

The only workable approach I see is to provide enforcer style protection for
old programs (breaks only a few poorly written/tested programs).  All tasks
can read/write all other tasks; however, access of free or non-existant memory
will kill a large percentage of "bad" programs.

It may be possible (with great effort) to add new modes of protected memory
for new programs/libraries/devices/resources.  The problems with this are of
course major changes required of the OS, the possible requirement that new
programs only open new libraries/datatypes/devices/resources, the possible
requirement that new libraries/datatypes/devices/resources are never called by
old programs... just to name a few.

--------------------------------------------------------------------------
- Richard Deken                   E-Mail: (personal)     [e-mail] -
- VLSI design engineer                    (AuE business) [e-mail]     -
- Advanced Microelectronics       PGP public key available               -
--------------------------------------------------------------------------